前言

功能完成得差不多了，還不完整但可以動，活動紀錄、跟活動詳細頁的實做我沒有寫成文章但是沒有關係，讓我簡單介紹後，直接進入正題。

MyMomentum 是我正在開發的一個個人習慣追蹤工具，讓使用者可以記錄活動並回顧習慣。

進入正題

我以前做過不少 side project，大部分停留在「本機可以跑」的階段。這次做 MyMomentum 的時候，從一開始就決定要把完成的網站「上線」。

但是老實說，實務上我並不常有網站架設的經驗，尤其是整個網際網路都能接觸到的網站，有什麼工作要做？ 要懂什麼？ 通通都是一知半解。

這篇文章想跟大家分享，我第一次認真規劃上線的思考過程，從零概念到逐步描繪出一張藍圖。

什麼叫做「上線」？

在這之前，我對「上線」的理解很單純：

• 本機能跑 = 可以用了。
• 把程式放到伺服器上 = 上線成功。

但真的開始規劃後，我發現事情不是這樣。真正的上線，代表服務能夠穩定、方便，讓別人隨時打開來用。 這背後涉及到：

• 執行環境要怎麼準備？
• 資料庫放哪裡？
• 前端跟後端要怎麼協作？
• 要不要自動化部署？

這些問題讓我重新思考：「原來上線不是能動就好，而是一連串的決策與執行。」

遇到的第一批問題

在一開始，我馬上被幾個問題卡住：

• 資料庫要放哪裡？

  → 一開始我想直接用 VPS (虛擬私有伺服器)跑 Docker Postgres，後來發現其實也可以把 DB 分離成獨立服務(如:Amazon RDS)。

• 後端要怎麼跑？

  → Spring Boot 可以直接 java -jar，但其實也可以用 Docker 來跑。

• 前端要怎麼跑？

  → React build 出來的是靜態檔，需要 Web Server（Nginx / Apache），這我並不熟悉。

• 要不要 CI/CD？

  → 短期內可能手動部署就行，但長期來看，CI/CD 可以省下我更新部屬的麻煩、找工作或聊天也可以稍微扯一下。

這些「原本以為很簡單，結果一查才發現一堆細節」的體驗，像是炸彈轟炸我的腦袋，好麻煩啊

不過就像是解鎖了新的領域，我瞭解到：上線是一種完整的工程思維，不只是把程式丟上去。

我的三階段上線規劃

經過一番思考，我把 MyMomentum 的上線拆成三個階段，避免一次吃下太多複雜度。

• 短期：能在網路上打開
  • 租一台 VPS
  • 用 Docker Compose 跑前端（Nginx）、後端（Spring Boot）、資料庫（Postgres）
  • 至少有一個公開網址能 demo，功能能跑起來
• 中期：專業展示
  • 把資料庫分離到雲端服務（RDS、Supabase 等）
  • 加上 CI/CD pipeline（GitHub Actions），push code 後自動 build image 並部署
  • 雖然網站功能齊全，但要能「幫得上忙」還得再開發一段時間，所以自動部屬，加上我想玩玩看 (尤其是CI/CD)
  • 資料庫分離原本的 VPS ，則是因為我騙自己將來使用者會很多
• 長期：服務演進
  • 加上監控（health check、APM、Prometheus、ELK）(但功能那麼少，應該是不用)
  • 資料庫備援 / 定期備份
  • 視使用者成長，考慮 Kubernetes 或雲端 auto-scaling (但功能那麼少，應該是不用)

期許自己不是以「一次到位」的心態來做這件事，因為我肯定會遇到很多沒碰過的東西，一步一腳印慢慢來。

沒有人在用，為什麼要這麼搞剛？(台語)

主要是不管怎麼樣，我希望真的有人用這個服務並且被它幫助。

在開發過程中，我發現我對「MyMomentum」的期許越來越大 ( 當然也有可能是自己花了這些時間不想浪費 )。

總之我開始覺得，就算前中期我所付出的時間精力與金錢都白費，長期下來這些投資還是會幫到我

只要我持續投入

MyMomentum 可以做為我個人的習慣教練，令我不管做什麼都有聲有色，其他就當作多餘的

以此為出發點，我覺得現在做的這些工作，搞剛一點也沒關係

套一句我朋友說的話 「挖塞，你喜歡沒苦硬吃啊」

結語

下一步是先用 Docker Compose 跑出第一個能公開存取的版本。之後再逐漸往 DB 分離、CI/CD、自動化演進，儘量照著三階段變化走。